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Design Goals for Scalable Internet Routing 


Abstract 


It is commonly recognized that the Internet routing and addressing 
architecture is facing challenges in scalability, mobility, multi- 
homing, and inter-domain traffic engineering. The Routing Research 
Group is investigating an alternate architecture to meet these 
challenges. This document consists of a prioritized list of design 
goals for the target architecture. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Research Task Force 
(IRTF). The IRTF publishes the results of Internet-related research 
and development activities. These results might not be suitable for 
deployment. This RFC represents the consensus of the Routing 
Research Group of the Internet Research Task Force (IRTF). Documents 
approved for publication by the IRSG are not a candidate for any 
level of Internet Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6227. 


Copyright Notice 


Copyright (c) 2011 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. 
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1. Introduction 


It is commonly recognized that the Internet routing and addressing 
architecture is facing challenges in inter-domain scalability, 
mobility, multi-homing, and inter-domain traffic engineering 
[RFC4984]. The Routing Research Group (RRG) aims to design an 


alternate architecture to meet these challenges. This document 
presents a prioritized list of design goals for the target 
architecture. 


These goals should be taken as guidelines for the design and 
evaluation of possible architectural solutions. The expectation is 
that these goals will be applied with good judgment. 


The goals presented here were initially presented and discussed at 
the start of the RRG work on a revised routing architecture, and were 
revisited and finalized after the work on that architecture was 
complete. As such, this represents both the goals that the RRG 
started with, and revisions to those goals based on our increased 
understanding of the space. 
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1. Requirements Language 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 
-2. Priorities 
Each design goal in this document has been assigned a priority, which 
is one of the following: ’required’, ‘’strongly desired’, or 
‘desired’. 
Required: 
The solution is REQUIRED to support this goal. 
Strongly desired: 
The solution SHOULD support this goal, unless there exist 
compelling reasons showing that it is unachievable, extremely 
inefficient, or impractical. 
Desired: 
The solution SHOULD support this goal. 
General Design Goals Collected from the Past 
[RFC1958] provides a list of the original architectural principles of 
the Internet. We incorporate them here by reference, as part of our 
desired design goals. 
Design Goals for a New Routing Architecture 
1. Improved Routing Scalability 


Long experience with inter-domain routing has shown that the global 
BGP routing table is continuing to grow rapidly [BGPGrowth]. 
Carrying this large amount of state in the inter-domain routing 
protocols is expensive and places undue cost burdens on network 
participants that do not necessarily get value from the increases in 
the routing table size. Thus, the first required goal is to provide 
significant improvement to the scalability of the inter-domain 
routing subsystem. It is strongly desired to make the routing 
subsystem scale independently from the growth of the Internet user 
population. If there is a coupling between the size of the user base 
and the scale of the routing subsystem, then it will be very 
difficult to retain any semblance of scalability. If a solution 
includes support for alternative routes to support faster 
convergence, the alternative routes should also factor into routing 
subsystem scalability. 
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3.2. Scalable Support for Traffic Engineering 


Traffic engineering is the capability of directing traffic along 
paths other than those that would be computed by normal IGP/EGP 
routing. Inter-domain traffic engineering today is frequently 
accomplished by injecting more-specific prefixes into the global 
routing table, which results in a negative impact on routing 
scalability. The additional prefixes injected to enable traffic 
engineering place an added burden on the scalability of the routing 
architecture. At the same time, the need for traffic engineering 
capabilities is essential to network operations. Thus, a scalable 
solution for inter-domain traffic engineering is strongly desired. 


3.3. Scalable Support for Multi-Homing 


Multi-homing is the capability of an organization to be connected to 
the Internet via more than one other organization. The current 
mechanism for supporting multi-homing is to let the organization 
advertise one prefix or multiple prefixes into the global routing 
system, again resulting in a negative impact on routing scalability. 
More scalable solutions for multi-homing are strongly desired. 


3.4. Decoupling Location and Identification 


Numerous sources have noted that an IP address embodies both host 
attachment point information and identification information [IEN1]. 
This overloading has caused numerous semantic collisions that have 
limited the flexibility of the Internet architecture. Therefore, it 
is desired that a solution separate the host location information 
namespace from the identification namespace. 


Caution must be taken here to clearly distinguish the decoupling of 
host location and identification information, and the decoupling of 
end-site addresses from globally routable prefixes; the latter has 
been proposed as one of the approaches to a scalable routing 
architecture. Solutions to both problems, i.e., (1) the decoupling 
of host location and identification information and (2) a scalable 
global routing system (whose solution may, or may not, depend on the 
second decoupling) are required, and it is required that their 
solutions are compatible with each other. 
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5. Scalable Support for Mobility 


Mobility is the capability of a host, network, or organization to 
change its topological connectivity with respect to the remainder of 
the Internet, while continuing to receive packets from the Internet. 
Existing mechanisms to provide mobility support include 


1. renumbering the mobile entity as it changes its topological 
attachment point(s) to the Internet; 


2. renumbering and creating a tunnel from the entity’s new 
topological location back to its original location; and 


3. letting the mobile entity announce its prefixes from its new 
attachment point(s). 


The first approach alone is considered unsatisfactory, as the change 
of IP address may break existing transport or higher-level 
connections for those protocols using IP addresses as identifiers. 
The second requires the deployment of a ’home agent’ to keep track of 
the mobile entity’s current location and adds overhead to the routers 
involved, as well as adding stretch to the path of an inbound packet. 
Neither of the first two approaches impacts the routing scalability. 
The third approach, however, injects dynamic updates into the global 
routing system as the mobile entity moves. Mechanisms that help to 
provide more efficient and scalable mobility support are desired, 
especially when they can be coupled with security -- especially 
privacy -- and support topological changes at a high rate. Ideally, 
such mechanisms should completely decouple mobility from routing. 


6. Simplified Renumbering 


Today, many of the end-sites receive their IP address assignments 
from their Internet Service Providers (ISPs). When such a site 
changes providers, for routing to scale, the site must renumber into 
a new address block assigned by its new ISP. This can be costly, 
error-prone, and painful [RFC5887]. Automated tools, once developed, 
are expected to provide significant help in reducing the renumbering 
pain. It is not expected that renumbering will be wholly automated, 
as some manual reconfiguration is likely to be necessary for changing 
the last-mile link. However, the overall cost of renumbering should 
be drastically lowered. 


In addition to being configured into hosts and routers, where 
automated renumbering tools can help, IP addresses are also often 
used for other purposes, such as access control lists. They are also 
sometimes hard-coded into applications used in environments where 
failure of the DNS could be catastrophic (e.g., certain remote 
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monitoring applications). Although renumbering may be considered a 
mild inconvenience for some sites, and guidelines have been developed 
for renumbering a network without a flag day [RFC4192], for others, 
the necessary changes are sufficiently difficult so as to make 
renumbering effectively impossible. It is strongly desired that a 
new architecture allow end-sites to renumber their network with 
significantly less disruption, or, if renumbering can be eliminated, 
the new architecture must demonstrate how the topology can be 
economically morphed to fit the addressing. 


7. Modularity, Composability, and Seamlessness 


A new routing architecture should be modular: it should subdivide 
into multiple composable, extensible, and orthogonal subsystems. The 
interfaces between modules should be natural and seamless, without 
special cases or restrictions. Similarly, the primitives and 
abstractions in the architecture should be suitably general, with 
operations equally applicable to abstractions and concrete entities, 
and without deleterious side-effects that might hinder communication 
between endpoints in the Internet. These properties are strongly 
desired in a solution. 


As an example, if tunneling were used as a part of a solution, 
tunneling should be completely transparent to both of the endpoints, 
without requiring new mechanisms for determining the correct maximum 
datagram size. 


The resulting network should always fully approximate the current 
best-effort Internet connectivity model, and it should also 
anticipate changes to that model, e.g., for multiple differentiated 
and/or guaranteed levels of service in the future. 


8. Routing Quality 


The routing subsystem is responsible for computing a path from any 
point in the Internet to any other point in the Internet. The 
quality of the routes that are computed can be measured by a number 
of metrics, such as convergence, stability, and stretch. 


The stretch factor is the maximum ratio between the length of a 
route computed by the routing scheme and that of a shortest path 
connecting the same pair of nodes [JACM89]. 


A solution is strongly desired to provide routing quality equivalent 
to what is available today, or better. 
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9. Routing Security 


Currently, the routing subsystem is secured through a number of 
protocol-specific mechanisms of varying strength and applicability. 
Any new architecture is required to provide at least the same level 
of security as is deployed as of when the new architecture is 
deployed. 


10. Deployability 


A viable solution is required to be deployable from a technical 
perspective. Furthermore, given the extensive deployed base of 
today’s Internet, a solution is required to be incrementally 
deployable. This implies that a solution must continue to support 
those functions in today’s routing subsystem that are actually used. 
This includes, but is not limited to, the ability to control routing 
based on policy. 


11. Summary of Priorities 
The following table summarizes the priorities of the design goals 
discussed above. 
4+------------------------ 4+------------------ + 
| Design goal | Priority 
4+------------------------ 4+------------------ + 
| Scalability | Strongly desired | 
Traffic engineering | Strongly desired | 
| Multi-homing Strongly desired 
| Loc/id separation | Desired 
| Mobility | Desired 
| Simplified renumbering | Strongly desired | 
| Modularity | Strongly desired | 
| Routing quality | Strongly desired | 
Routing security Required 
| Deployability | Required 
4+------------------------ 4+------------------ + 
Security Considerations 
All solutions are required to provide security that is at least as 
strong as the existing Internet routing and addressing architecture. 
This document does not suggest any default architecture or protocol, 
and thus this document introduces no new security issues. 
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